Content streaming typically involves a client receiving requested primary content from a first server and advertisements or other third party content presented during breaks of the primary content from different third party servers. Streaming provides a direct one-to-one connection between the sending server and the receiving client. The one-to-one connection allows the sending server to track client progression through the sent content. This tracking is especially beneficial for advertisers and third party content providers as it allows them to more accurately determine advertising campaign effectiveness as well as more accurately determine payments related to the advertisement presentation.
To combat advertisement blockers and simplify logic on the client player, some streaming providers have shifted to a pure server-side streaming solution. The server-side streaming solution provides a single stream to a client. Embedded within that single stream are the primary media content, different advertisements, and other third party content not part of the primary media content. The client therefore receives the primary media content, different advertisements, and other third party content forming the single stream without switching between streams, Uniform Resource Locators (URLs), or servers. As a result, the client or advertisement blockers running on the client cannot differentiate between the different content in the single stream, which in turn prevents the client or advertisement blockers from blocking advertisements or other third party content while allowing the primary content.
Such a pure server-side streaming solution has various incompatibilities with traditional impression tracking and reporting. In particular, the different content providers whose content are included in the single stream no longer have the one-to-one direct connection with the client. Instead, the server sending the single stream tracks when playback at a client reaches certain milestones or impressions for each of the different content that is combined to form the single stream. The server then distributes the tracking beacons to the advertisers and third party content providers whose content is combined in the single stream. The server-side streaming solution therefore requires a shift from traditional client-side beacon tracking to server-side beacon tracking.
With traditional client-side beacon tracking, the advertisers or third party content providers collect each client generated tracking beacon from the Internet Protocol (IP) address of that client. With server-side beacon tracking, the streaming server collects tracking beacons for all clients viewing the single stream from the streaming server. The streaming server then sends the collective bundle of beaconing information for all users to the advertisers or third party content providers. In other words, an advertiser receives the collective bundle of beaconing information for different clients from a single Internet Protocol (IP) address of the streaming server.
In some cases, the advertisers or third party content providers ignore the collective bundle of beaconing information provided by the streaming server because the volume of beaconing information is too large to come from a single source. In some other cases, the advertisers or third party content providers cannot correctly process the collective bundle of beaconing information provided by the streaming server because the advertisers or third party content providers are unable to accurately map the individual tracking beacons back to the individual clients that generated the tracking beacons.
The server-side beacon tracking also restricts the advertisers and third party content provider from being able to customize the information that is reported and when it is reported. The advertisers and third party content providers are dependent on when and what beaconing information is collected from the individual clients by the streaming server.
The inability to customize the reported tracking beacons could result in incompatibilities with the content provider's existing systems or result in tracking beacons that lack information needed or that is pertinent to the content provider. In particular, the server-side beacon tracking can disrupt programmatic advertisement insertion performed by some content providers, whereby content providers rely on tracking beacons reported on a per session, per client player, or per advertisement basis in order to target advertisements and other third party content to different clients.
Also, by losing the direct connections with the clients as a result of the server-side beacon tracking, the content providers lose the ability to access certain client information that is not available or is unrelated to the tracking beacons. For example, some content providers rely on information inserted in cookies on the client machine or client device identifiers to enhance the impression tracking or perform other functions such as programmatic advertisement insertion.
Accordingly, there is a need to adapt a pure server-side streaming solution to incorporate aspects of client-side beacon tracking. There is a need to remove the streaming server as the middle layer collecting and reporting tracking beacons from clients to different third party content providers. Stated differently, there is a need for the streaming server to deliver a single stream that embeds third party content directly with primary content, and for the third party content providers to derive custom tracking beacons directly from the clients receiving the single stream.